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DETAILED ACTION 

1. Applicant's amendment dated Marcli 21 , 2008, responding to tine Office action 
mailed September 21, 2007 provided in the rejection of claims 1-45, wherein claims 1, 
15, 28, and 32 were amended, claims 2 and 29 were canceled. 

Claims 1, 3-28, and 30-45 remain pending in the application and which have 
been fully considered by the examiner. 

Applicant's arguments with respect to claims currently amended have been fully 
considered but are moot in view of the new grounds of rejection - see Zorc - art made of 
record, as applied hereto. 

Applicant's amendment necessitated the new ground(s) of rejection presented in 
this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 
Applicant Is reminded of the extension of time policy as set forth in 37 CFR 1 .136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 
1 .136(a) will be calculated from the mailing date of the advisory action. In no event, however, 
will the statutory period for reply expire later than SIX MONTHS from the date of this final 
action. 
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Claim Rejections - 35 USC § 103(a) 

The following is a quotation of 35 U.S.C. 103(a) wliicli forms tine basis for all 
obviousness rejections set forth in this office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 1 02 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

2. Claims 1-13, 15-22, 28-35, 37, 39, 43, and 45 are rejected under 35 U.S.C. 
103(a) as being unpatentable over Samo Zorc (Pub. No. US 2003/0167444 A1) 
(hereinafter 'Zorc' - art made of record) in view of Michael Koch {Leverage legacy 
systems with a blend of XML, XSL, and Java®, October 6, 2000, JavaWorld.com) 
(hereinafter 'Koch') 

3. As to claim 1 (Currently Amended), Zorc discloses a method of processing 
messages comprising: 

• receiving a markup language document describing a message (e.g.. Fig. 2, 
XML Message Definition; [0009] - ... directly from an XML schema message 
definition ): 

• automatically generating source code in a program language from the markup 
language document (e.g., [0010] - ... automatically generating source code 
based on a mark-up language message definition ...); and 

• compiling the source code (e.g., [0009] - ... a mechanism is provided for 
automatically generating a conversion module directly from an XML schema 
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message definition ; [0010]; [0026] - ... a compilation mechanism for 
automatically generating the conversion module ...) 

Further, Zorc discloses a method and system for automatically generating source 
code based on a mark-up language message definition (e.g.. Abstract) and conversion 
modules that convert some kind of internal representation of the data to an external 
representation (e.g., a specified communication message in XML format) and vice versa 
(e.g., [0023]-[0025]; [0098]), but does not explicitly disclose the markup language 
document being compliant with message rules associated with an OLTP language; 
using the compiled source code to transform a payload message between the program 
language and the online transaction processing (OLTP) language. 

However, in an analogous art of Leverage Legacy Systems with a blend of XML, 
XSL, and Java, Koch discloses: 

• the markup language document being compliant with message rules associated 
with an OLTP language (e.g., P. 5, Sec. of "Conclusion" - XML, XSL, and Java ® 
work hand in hand to solve the complex problem of mainframe transaction 
access ... XML allows us to describe the structure of the COBOL transaction 
(compliant with message rules associated with an OLTP language), providing 
directions to the Java® engine on how to build the request or parse the response 

...); 

• using the compiled source code to transform a payload message between the 
program language and the online transaction processing (OLTP) language (e.g., 
P. 2, Sec. of "XSL Style", 2"" Par. - ... use XSL to format an incoming document 
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structure to the name/value-pair structure ... which the Java® code processes 
into the COBOL structure . XSL will also format the data returned from the legacy 
system ... Java code transforms it back into XML Sec. of "Combine XML, 
XSL, and Java to interface with mainframe systems", 2"^^ Par. - XML describes 
the structure of the data you are sending; Add XSL to complete some simple 
transformations; Use Java® to encapsulate it with a few simple classes; You will 
then leverage a host of legacy system transactions written decades ago and 
development becomes easier; In addition, the solution, you employ is realtime, 
which circumvents the frustrations and problems that arise from working with an 
extract file or batch interface; Fig. 1 - Legacy transaction framework, elements of 
"Calling Application", "Java Engine", "Outgoing message structure", "Incoming 
message structure", and "Legacy System"; Sec. of "Conclusion" - XML, XSL, and 
Java work hand in hand to solve the complex problem of mainframe transaction 
access; Implementing XSL styling creates supplementary layers in the framework 
that allow the solution to configure changes from the application server or the 
mainframe programs without recompiling the Java code that performs the 
mapping; XML allows us to describe the structure of the COBOL transactions, 
providing directions to the Java® engine on how to build the request or parse the 
response) 

Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of Koch into the Zorc's system to 
further provide the markup language document being compliant with message rules 
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associated witli an OLTP language; using the compiled source code to transform a 
payload message between the program language and the online transaction processing 
(OLTP) language in Zorc system. 

The motivation is that it would further enhance the Zorc's system by taking, 
advancing and/or incorporating Koch's system which offers significant advantages that 
XML allows us to describe the structure of the COBOL transaction, providing directions 
to the Java® engine on how to build the request or parse the response as once 
suggested by Koch (e.g., P. 5, Sec. of "Conclusion") 

4. As to claim 2 (Original) (incorporating the rejection in claim 1), Koch discloses 
the method further including: receiving a markup language document, the markup 
language document being compliant with message rules associated with the OLTP 
language (e.g., P. 5, Sec. of "Conclusion" - XML . XSL, and Java ® work hand in hand to 
solve the complex problem of mainframe transaction access ... XML allows us to 
describe the structure of the COBOL transaction (compliant with message rules 
associated with an OLTP language), providing directions to the Java® engine on how to 
build the request or parse the response Sec. of "Combine XML, XSL, and Java to 
interface with mainframe systems", 2"^^ Par. - XML describes the structure of the data 
you are sending; Add XSL to complete some simple transformations; Use Java® to 
encapsulate it with a few simple classes; You will then leverage a host of legacy system 
transactions written decades ago and development becomes easier; In addition, the 
solution, you employ is realtime, which circumvents the frustrations and problems that 
arise from working with an extract file or batch interface; Fig. 1 - Legacy transaction 
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framework, elements of "Calling Application", "Java Engine", "Outgoing message 
structure", "Incoming message structure", and "Legacy System"; Sec. of "Conclusion" - 
XML, XSL, and Java work hand 1 hand to solve the complex problem of mainframe 
transaction access; Implementing XSL styling creates supplementary layers in the 
framework that allow the solution to configure changes from the application server or 
the mainframe programs without recompiling the Java code that performs the mapping; 
XML allows us to describe the structure of the COBOL transactions, providing directions 
to the Java® engine on how to build the request or parse the response); and Zorc 
discloses compiling the markup language document into the source code (e.g., [0010] - 
... automatically generating source code based on a mark-up language message 
definition ...); and further Koch discloses the source code enabling transformation of 
the message between the program language and the OLTP language (e.g., P. 2, Sec. 
of "XSL Style", 2"^ Par. - . . . use XSL to format an incoming document structure to the 
name/value-pair structure ... which the Java® code processes into the COBOL 
structure . XSL will also format the data returned from the legacy system ... Java code 
transforms it back into XML ...) 

5. As to claim 3 (Original) (incorporating the rejection in claim 2), Koch discloses 
the method wherein the message rules define markup tags for describing components 
of the message (e.g.. Sec. of "The versatile XML, 3"^ Par. - Using XML, you can now 
implement that copybook metadata to generate your copybook markup language; 
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Below, this short, simplistic example of an XML document containing our COBOL 
program's metadata retrieves a name when given a social security number) 

6. As to claim 4 (Original) (incorporating the rejection in claim 3), Koch discloses 

the method wherein the message is a request message from an application to an OLTP 
host (e.g., Fig. 1 - Legacy transaction framework, elements of "outgoing message 
structure", "incoming message structure"). 

7. As to claim 5 (Original) (incorporating the rejection in claim 3), Koch discloses 
the method wherein the message is a response message from an OLTP host to an 
application (e.g.. Fig. 1 - Legacy transaction framework, elements of "outgoing 
message structure", "incoming message structure"). 

8. As to claim 6 (Original) (incorporating the rejection in claim 3), Koch discloses 
the method wherein the markup language is an extensible markup language (e.g., Sec. 
of "Combine XML, XSL, and Java to interface with mainframe systems", 2"'' Par. - XML 
describes the structure of the data you are sending; Add XSL to complete some simple 
transformations; Use Java® to encapsulate it with a few simple classes; You will then 
leverage a host of legacy system transactions written decades ago and development 
becomes easier; In addition, the solution, you employ is realtime, which circumvents the 
frustrations and problems that arise from working with an extract file or batch interface). 
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9. As to claim 7 (Original) (incorporating the rejection in claim 2), Koch discloses 
the method further including compiling the markup language document based on 
stylesheet data, the stylesheet data representing a program template for the message in 
the program language (e.g., P. 2, Sec. of "XSL Style", 2"^^ Par. - ... use XSL to format an 
incoming document structure to the name/value-pair structure . . . which the Java® code 
processes into the COBOL structure . XSL will also format the data returned from the 
legacy system ... Java code transforms it back into XML ...) 

10. As to claim 8 (Original) (incorporating the rejection in claim 7), Koch discloses 
the method further including using a stylesheet parser to compile the markup language 
document (e.g., P. 2, Sec. of "XSL Style", 2"^^ Par. - ... use XSL to format an incoming 
document structure to the name/value-pair structure . . . which the Java® code 
processes into the COBOL structure . XSL will also format the data returned from the 
legacy system ... Java code transforms it back into XML ...) 

11. As to claim 9 (Original) (incorporating the rejection in claim 2), Zorc discloses 
the method further including receiving and compiling a plurality of markup language 
documents for a plurality of message types (e.g., [0009] - ... a mechanism is provided 
for automatically generating a conversion module directly from an XML schema 
message definition : [0010]; [0026] - ... a compilation mechanism for automatically 
generating the conversion module ...) 



Application/Control Number: 1 0/681 ,057 Page 1 0 

Art Unit: 2192 

12. As to claim 10 (Original) (incorporating the rejection in claim 1), Zorc discloses 
the method wherein the program language is an object-oriented program language 
(e.g., [0023] - ... for generating or receiving object-oriented code (e.g., Java® objects)) 

13. As to claim 11 (Original) (incorporating the rejection in claim 10), Koch discloses 
the method further including: 

• receiving one or more name-value pairs for the message according to the object- 
oriented program language (e.g., P. 5, 1®' bullet - since XSL is applied to the 
incoming document as well as the outgoing document, the Java engine, once 
written, is insulated from changes in the incoming message structure; the entire 
DTD, or schema, of the incoming message could be changed completely; a 
programmer would only have to modify the XSL within this framework that styles 
the document into your name/value-pair format; 1®' Par. [after program listing] - 
essentially, the code matches the fields with value from the array and creates 
name/value pairs that are suitable for simplistic XML document); 

• generating a byte array according to the OLTP language; and transmitting the 
byte array to an application (e.g., 1®' Par. [after program listing] - data 
manipulation transforms the response from a byte array or similar structure into 
an XML document; essentially, the code matches the fields with value from the 
array and creates name/value pairs that are suitable for simplistic XML 
document). 
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14. As to claim 12 (Original) (incorporating tlie rejection in claim 10), Koch discloses 
the method further including: receiving a byte array for the message according to the 
OLTP language; generating one or more name-value pairs according to the object- 
oriented program language; and transmitting the name-value pairs to an application 
(e.g., P. 5, 1^' bullet - since XSL is applied to the incoming document as well as the 
outgoing document, the Java engine, once written, is insulated from changes in the 
incoming message structure; the entire DTD, or schema, of the incoming message 
could be changed completely; a programmer would only have to modify the XSL within 
this framework that styles the document into your name/value-pair format; 1®' Par. [after 
program listing] - essentially, the code matches the fields with value from the array and 
creates name/value pairs that are suitable for simplistic XML document). 

15. As to claim 13 (Original) (incorporating the rejection in claim 10), Koch discloses 
the method wherein the object-oriented program language is a Java language (e.g., 
Sec. of "Combine XML, XSL, and Java to interface with mainframe systems", 2"'' Par. - 
XML describes the structure of the data you are sending; Add XSL to complete some 
simple transformations; Use Java® to encapsulate it with a few simple classes; You will 
then leverage a host of legacy system transactions written decades ago and 
development becomes easier; In addition, the solution, you employ is realtime, which 
circumvents the frustrations and problems that arise from working with an extract file or 
batch interface). 
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16. As to claim 15 (Currently Amended), Zorc discloses a method of generating 
source code comprising: 

• receiving a markup language document (e.g., Fig. 2, XML Message Definition; 
[0009] "... directly from an XML schema message definition ): and 

• automatically generating a source code based on the markup language 
document (e.g., [0010] - ... automatically generating source code based on a 
mark-up language message definition ...) 

Further, Zorc discloses a method and system for automatically generating source 
code based on a mark-up language message definition (e.g., Abstract) and conversion 
modules that convert some kind of internal representation of the data to an external 
representation (e.g., a specified communication message in XML format) and vice versa 
(e.g., [0023]-[0025]; [0098]), but does not explicitly disclose the markup language 
document being compliant with message rules associated with an online transaction 
processing (OLTP) language; and the source code enabling transformation of a payload 
message between a program language and the OLTP language; 

However, in an analogous art of Leverage Legacy Systems with a blend of XML, 
XSL, and Java, Koch discloses: 

• the markup language document being compliant with message rules associated 
with an online transaction processing (OLTP) language (e.g., P. 5, Sec. of 
"Conclusion" - XML . XSL, and Java ® work hand in hand to solve the complex 
problem of mainframe transaction access ... XML allows us to describe the 
structure of the COBOL transaction (compliant with message rules associated 
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with an OLTP language), providing directions to the Java® engine on how to 
build the request or parse the response ...); and 
• the source code enabling transformation of a payload message between a 
program language and the OLTP language (e.g., Sec. of "Combine XML, XSL, 
and Java to interface with mainframe systems", 2"^* Par. - XML describes the 
structure of the data you are sending; Add XSL to complete some simple 
transformations; Use Java® to encapsulate it with a few simple classes; You will 
then leverage a host of legacy system transactions written decades ago and 
development becomes easier; In addition, the solution, you employ is realtime, 
which circumvents the frustrations and problems that arise from working with an 
extract file or batch interface; Fig. 1 - Legacy transaction framework, elements of 
"Calling Application", "Java Engine", "Outgoing message structure", "Incoming 
message structure", and "Legacy System"; Sec. of "Conclusion" - XML, XSL, and 
Java work hand in hand to solve the complex problem of mainframe transaction 
access; Implementing XSL styling creates supplementary layers in the framework 
that allow the solution to configure changes from the application server or the 
mainframe programs without recompiling the Java code that performs the 
mapping; XML allows us to describe the structure of the COBOL transactions, 
providing directions to the Java® engine on how to build the request or parse the 
response) 

Further, Zorc discloses a method and system for automatically generating source 
code based on a mark-up language message definition (e.g.. Abstract), but does not 
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explicitly disclose the markup language document being compliant with message rules 
associated with an online transaction processing (OLTP) language; and the source 
code enabling transformation of a payload message between a program language and 
the OLTP language in Zorc system. 

Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of Koch into the Zorc's system to 
further provide the markup language document being compliant with message rules 
associated with an online transaction processing (OLTP) language; the source code 
enabling transformation of a payload message between a program language and the 
OLTP language in Zorc system. 

The motivation is that it would further enhance the Zorc's system by taking, 
advancing and/or incorporating Koch's system which offers significant advantages that 
XML allows us to describe the structure of the COBOL transaction, providing directions 
to the Java® engine on how to build the request or parse the response as once 
suggested by Koch (e.g., P. 5, Sec. of "Conclusion") 

17. As to claim 16 (Original) (incorporating the rejection in claim 15), Koch discloses 
the method wherein the message rules define markup tags for describing components 
of the message (e.g., Sec. of "Combine XML, XSL, and Java to interface with 
mainframe systems", 2"^ Par. - XML describes the structure of the data you are 
sending; Add XSL to complete some simple transformations; Use Java® to encapsulate 
it with a few simple classes; You will then leverage a host of legacy system transactions 
written decades ago and development becomes easier; In addition, the solution, you 
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employ is realtime, which circumvents the frustrations and problems that arise from 
working with an extract file or batch interface; Fig. 1 - Legacy transaction framework, 
elements of "Calling Application", "Java Engine", "Outgoing message structure", 
"Incoming message structure", and "Legacy System"; Sec. of "Conclusion" - XML, XSL, 
and Java work hand i hand to solve the complex problem of mainframe transaction 
access; Implementing XSL styling creates supplementary layers in the framework that 
allow the solution to configure changes from the application server or the mainframe 
programs without recompiling the Java code that performs the mapping; XML allows us 
to describe the structure of the COBOL transactions, providing directions to the Java® 
engine on how to build the request or parse the response). 

18. As to claim 17 (Original) (incorporating the rejection in claim 16), Koch discloses 

the method wherein the message is a request message from an application to an OLTP 
host (e.g., Fig. 1 - Legacy transaction framework, elements of "outgoing message 
structure", "incoming message structure"). 

19. As to claim 18 (Original) (incorporating the rejection in claim 16), Koch discloses 
the method wherein the message is a response message from an OLTP host to an 
application (e.g.. Fig. 1 - Legacy transaction framework, elements of "outgoing 
message structure", "incoming message structure"). 
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20. As to claim 19 (Original) (incorporating the rejection in claim 16), Koch discloses 
the method wherein the markup language is an extensible markup language (e.g.. Sec. 
of "Combine XML, XSL, and Java to interface with mainframe systems", 2"^ Par. - XML 
describes the structure of the data you are sending; Add XSL to complete some simple 
transformations; Use Java® to encapsulate it with a few simple classes; You will then 
leverage a host of legacy system transactions written decades ago and development 
becomes easier; In addition, the solution, you employ is realtime, which circumvents the 
frustrations and problems that arise from working with an extract file or batch interface). 

21 . As to claim 20 (Original) (incorporating the rejection in claim 15), Koch discloses 
the method further including compiling the markup language document based on 
stylesheet data, the stylesheet data representing a program template for the message in 
the program language (e.g., P. 2, Sec. of "XSL Style", 2"^^ Par. - ... use XSL to format an 
incoming document structure to the name/value-oair structure ... which the Java® code 
processes into the COBOL structure . XSL will also format the data returned from the 
legacy system ... Java code transforms it back into XML ...) 

22. As to claim 21 (Original) (incorporating the rejection in claim 20), Koch discloses 
the method further including using a stylesheet parser to compile the markup language 
document (e.g., P. 2, Sec. of "XSL Style", 2"^^ Par. - ... use XSL to format an incoming 
document structure to the name/value-oair structure . . . which the Java® code 
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processes into the COBOL structure . XSL will also format tlie data returned from the 
legacy system ... Java code transforms it back into XML ...) 

23. As to claim 22 (Original) (incorporating the rejection in claim 15), Zorc discloses 

the method further including receiving and compiling a plurality of markup language 
documents for a plurality of message types (e.g., [0009] - ... a mechanism is provided 
for automatically generating a conversion module directly from an XML schema 
message definition : [0010]; [0026] - ... a compilation mechanism for automatically 
generating the conversion module ...) 

24. As to claim 28 (Currently Amended), Zorc discloses a message processing 
architecture comprising: 

• a development module, the development module to receive a markup language 
document (e.g., Fig. 2, XML Message Definition; [0009] - ... directly from an XML 
schema message definition ) and automatically generate a source code in a 
program language (e.g., [0010] - ... automatically generating source code based 
on a mark-up language message definition ...), the source code based on the 
markup language document ; and 

• A program compiler, the program compiler to compile the source code (e.g., 
[0009] "... a mechanism is provided for automatically generating a conversion 
module directly from an XML schema message definition : [0010]; [0026] - ... a 
compilation mechanism for automatically generating the conversion module ...); 
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Further, Zorc discloses a metlnod and system for automatically generating source 
code based on a mark-up language message definition (e.g.. Abstract) and conversion 
modules that convert some kind of internal representation of the data to an external 
representation (e.g., a specified communication message in XML format) and vice versa 
(e.g., [0023]-[0025]; [0098]), but does not explicitly disclose the markup language 
document to be compliant with message rules associated with the OLTP language; and 
the source code to enable transformation of the message between the program 
language and the OLTP language; the message parser to transform a payload message 
between the program language and an online transaction processing (OLTP) language 
using the compiled source code. 

However, in an analogous art of Leverage Legacy Systems with a blend of XML, 
XSL, and Java, Koch discloses: 

• the markup language document to be compliant with message rules associated with 
the OLTP language (e.g., P. 5, Sec. of "Conclusion" - XML, XSL, and Java ® work 
hand in hand to solve the complex problem of mainframe transaction access . . . XML 
allows us to describe the structure of the COBOL transaction (compliant with 
message rules associated with an OLTP language), providing directions to the 
Java® engine on how to build the request or parse the response ...); and 

• the source code to enable transformation of the message between the program 
language and the OLTP language (e.g., P. 5, Sec. of "Conclusion" - XML . XSL, and 
Java ® work hand in hand to solve the complex problem of mainframe transaction 
access ... XML allows us to describe the structure of the COBOL transaction 
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(compliant with message rules associated with an OLTP language), providing 
directions to the Java® engine on how to build the request or parse the response 
...); and 

• the message parser to transform a payload message between the program 

language and an online transaction processing (OLTP) language using the compiled 
source code (e.g., P. 3, 1^' Par. - The Xerces parser allows for easy XML 
manipulation with in Java; Sec. of "Combine XML, XSL, and Java to interface with 
mainframe systems", 2"^^ Par. - XML describes the structure of the data you are 
sending; Add XSL to complete some simple transformations; Use Java® to 
encapsulate it with a few simple classes; In addition, the solution, you employ is 
realtime, which circumvents the frustrations and problems that arise from working 
with an extract file or batch interface; Fig. 1 - Legacy transaction framework, 
elements of "Calling Application", "Java Engine", "Outgoing message structure", 
"Incoming message structure", and "Legacy System"; Sec. of "Conclusion" - XML, 
XSL, and Java work hand in hand to solve the complex problem of mainframe 
transaction access; Implementing XSL styling creates supplementary layers in the 
framework that allow the solution to configure changes from the application server or 
the mainframe programs without recompiling the Java code that performs the 
mapping; XML allows us to describe the structure of the COBOL transactions, 
providing directions to the Java® engine on how to build the request or parse the 
response) 
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Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of Koch into the Zorc's system to 
further provide the markup language document to be compliant with message rules 
associated with the OLTP language; and the source code to enable transformation of 
the message between the program language and the OLTP language; the message 
parser to transform a payload message between the program language and an online 
transaction processing (OLTP) language using the compiled source code in Zorc 
system. 

The motivation is that it would further enhance the Zorc's system by taking, 
advancing and/or incorporating Koch's system which offers significant advantages that 
XML allows us to describe the structure of the COBOL transaction, providing directions 
to the Java® engine on how to build the request or parse the response as once 
suggested by Koch (e.g., P. 5, Sec. of "Conclusion") 

25. As to claim 29 (Original) (incorporating the rejection in claim 28), Zorc discloses 
the system wherein the development module is to receive a markup language document 
(e.g.. Fig. 2, XML Message Definition; [0009] - ... directly from an XML schema 
message definition ) and compile the markup document into the source code (e.g., 
[0009] - ... a mechanism is provided for automaticallv generating a conversion module 
directly from an XML schema message definition : [0010]; [0026] - ... a compilation 
mechanism for automatically generating the conversion module ...), and Koch discloses 
the markup language document to be compliant with message rules associated with the 
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OLTP language (e.g., P. 5, Sec. of "Conclusion" - XML , XSL, and Java ® work hand in 
hand to solve the complex problem of mainframe transaction access ... XML allows us 
to describe the structure of the COBOL transaction (compliant with message rules 
associated with an OLTP language), providing directions to the Java® engine on how to 
build the request or parse the response P. 1, 1^' Par., Lines 1-14 - The XSLT 
Compiler (XSLTC) is a "high-performance alternative to the Xalan Classic XSLT 
Processor for transforming XML documents into a variety of output formats; XSLTC is a 
free, open-source, Java®-based tool that generates fast and lightweight Java class files 
called translets that can be plugged into existing applications or used directly for 
transforming XML files according to an input XSL stylesheet; It assists developer who 
need high volume, portable, embedded XML transformation capabilities in their 
applications."; Lines 18-28 - These Java standards allow developers to send and 
receive SOAP messages, browse and retrieve information in UDDI and ebXML 
registries, and quickly build and deploy Web applications based on the latest JSP 
standards; Java® WSDP Version 1 .0_01 also includes: (1) Java XML Pack [Java® API 
for XML Messaging (JAXM); Java® API for XML Processing (JAXP) with XML Schema 
support; Java API for XML Registries (JAXR); Java API for XML-based RPC (JAX- 
RPC); SOAP with Attachments API for Java® (SAAJ)]; (2) JavaServer Pages Standard 
Tag Library [JSTL] (3) Java WSDP Registry Server; (4) Web Application Deployment 
Tool; ((5) Ant Build Tool; (6) Apache Tomact 4.1 .2 container; Lines 18-28 - These Java 
standards allow developers to send and receive SOAP messages, browse and retrieve 
information in UDDI and ebXML registries, and quickly build and deploy Web 
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applications based on the latest JSP standards; Java® WSDP Version 1 .0 01 also 
includes: (1) Java XML Pack [Java® API for XML Messaging (JAXM); Java® API for 
XML Processing (JAXP) with XML Schema support; Java API for XML Registries 
(JAXR); Java API for XML-based RPC (JAX-RPC); SOAP with Attachments API for 
Java® (SAAJ)]; (2) JavaServer Pages Standard Tag Library [JSTL] (3) Java WSDP 
Registry Server; (4) Web Application Deployment Tool; (5) Ant Build Tool; (6) Apache 
Tomact 4.1 .2 container) and Koch discloses the source code to enable transformation 
of the message between the program language and the OLTP language (e.g., Sec. of 
"Combine XML, XSL, and Java to interface with mainframe systems", 2"^ Par. - XML 
describes the structure of the data you are sending; Add XSL to complete some simple 
transformations; Use Java® to encapsulate it with a few simple classes; You will then 
leverage a host of legacy system transactions written decades ago and development 
becomes easier; In addition, the solution, you employ is realtime, which circumvents the 
frustrations and problems that arise from working with an extract file or batch interface). 

26. As to claim 30 (Original) (incorporating the rejection in claim 29), Koch discloses 
the system wherein the message rules define markup tags for describing components of 
the message (e.g.. Sec. of "Combine XML, XSL, and Java to interface with mainframe 
systems", 2"^ Par. - XML describes the structure of the data you are sending; Add XSL 
to complete some simple transformations; Use Java® to encapsulate it with a few 
simple classes; You will then leverage a host of legacy system transactions written 
decades ago and development becomes easier; In addition, the solution, you employ is 
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realtime, which circumvents the frustrations and problems that arise from working with 
an extract file or batch interface; Fig. 1 - Legacy transaction framework, elements of 
"Calling Application", "Java Engine", "Outgoing message structure", "Incoming message 
structure", and "Legacy System"; Sec. of "Conclusion" - XML, XSL, and Java work hand 
i hand to solve the complex problem of mainframe transaction access; Implementing 
XSL styling creates supplementary layers in the framework that allow the solution to 
configure changes from the application server or the mainframe programs without 
recompiling the Java code that performs the mapping; XML allows us to describe the 
structure of the COBOL transactions, providing directions to the Java® engine on how 
to build the request or parse the response). 

27. As to claim 31 (Original) (incorporating the rejection in claim 29), Koch discloses 

the system wherein the development module further includes a stylesheet parser, the 
development module to use the stylesheet parser to compile the markup language 
document based on stylesheet data (e.g., P. 2, Sec. of "XSL Style", 2"^^ Par. - ... use 
XSL to format an incoming document structure to the name/value-oair structure . . . 
which the Java® code processes into the COBOL structure . XSL will also format the 
data returned from the leaacv svstem ... Java code transforms it back into XML ...) 



28. As to claim 32 (Original), Zorc discloses a machine readable medium 
comprising a set of stored instructions capable of being executed by a processor to: 
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• receive a markup language document (e.g., Fig. 2, XML Message Definition; 
[0009] "... directly from an XML schema message definition ); and 

• automatically generating a source code based on the markup language 
document (e.g., [0010] - ... automatically generating source code based on a 
mark-up language message definition ...); 

Further, Zorc discloses a method and system for automatically generating source 
code based on a mark-up language message definition (e.g.. Abstract) and conversion 
modules that convert some kind of internal representation of the data to an external 
representation (e.g., a specified communication message in XML format) and vice versa 
(e.g., [0023]-[0025]; [0098]), but does not explicitly disclose the markup language 
document to be compliant with message rules associated with an online transaction 
processing (OLTP) language; the source code enabling transformation of a payload 
message between a program language and the OLTP language. 

However, in an analogous art of Leverage Legacy Systems with a blend of XML, 
XSL, and Java, Koch discloses: 

• the markup language document to be compliant with message rules associated 
with an online transaction processing (OLTP) language (e.g., Sec. of "Combine 
XML, XSL, and Java to interface with mainframe systems", 2"^^ Par. - XML 
describes the structure of the data you are sending; Add XSL to complete some 
simple transformations; Use Java® to encapsulate it with a few simple classes; 
You will then leverage a host of legacy system transactions written decades ago 
and development becomes easier; In addition, the solution, you employ is 
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realtime, which circumvents the frustrations and problems that ahse from working 
with an extract file or batch interface; Fig. 1 - Legacy transaction framework, 
elements of "Calling Application", "Java Engine", "Outgoing message structure", 
"Incoming message structure", and "Legacy System"; Sec. of "Conclusion" - 
XML, XSL, and Java work hand in hand to solve the complex problem of 
mainframe transaction access; Implementing XSL styling creates supplementary 
layers in the framework that allow the solution to configure changes from the 
application server or the mainframe programs without recompiling the Java code 
that performs the mapping; XML allows us to describe the structure of the 
COBOL transactions, providing directions to the Java® engine on how to build 
the request or parse the response); and 
• the source code enabling transformation of a payload message between a 
program language and the OLTP language (e.g., P. 5, Sec. of "Conclusion" - 
XML , XSL, and Java ® work hand in hand to solve the complex problem of 
mainframe transaction access ... XML allows us to describe the structure of the 
COBOL transaction (compliant with message rules associated with an OLTP 
language), providing directions to the Java® engine on how to build the request 
or parse the response ...) 

Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of Koch into the Zorc's system to 
further provide the markup language document to be compliant with message rules 
associated with an online transaction processing (OLTP) language; the source code 
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enabling transformation of a payload message between a program language and the 
OLTP language in Zorc system. 

The motivation is that it would further enhance the Zorc's system by taking, 
advancing and/or incorporating Koch's system which offers significant advantages that 
XML allows us to describe the structure of the COBOL transaction, providing directions 
to the Java® engine on how to build the request or parse the response as once 
suggested by Koch (e.g., P. 5, Sec. of "Conclusion") 

29. As to claim 33 (Original) (incorporating the rejection in claim 32), Koch discloses 
the medium wherein the message rules define markup tags for describing components 
of the message (e.g.. Sec. of "Combine XML, XSL, and Java to interface with 
mainframe systems", 2"^^ Par. - XML describes the structure of the data you are 
sending; Add XSL to complete some simple transformations; Use Java® to encapsulate 
it with a few simple classes; You will then leverage a host of legacy system transactions 
written decades ago and development becomes easier; In addition, the solution, you 
employ is realtime, which circumvents the frustrations and problems that arise from 
working with an extract file or batch interface). 

30. As to claim 34 (Original) (incorporating the rejection in claim 32), Koch discloses 
the medium wherein the instructions are further capable of being executed to compile 
the markup language document based on stylesheet data, the stylesheet data to 
represent a program template for the message in the program language (e.g., P. 2, Sec. 
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of "XSL Style", 2"'^ Par. - . . . use XSL to format an incoming document structure to the 
name/value-pair structure ... which the Java® code processes into the COBOL 
structure . XSL will also format the data returned from the legacy system ... Java code 
transforms it back into XML ...) 

31 . As to claim 35 (Original) (incorporating the rejection in claim 32), Zorc discloses 
the medium wherein the instructions are further capable of being executed to receive 
and compile a plurality of markup language documents for a plurality of message types 
(e.g., [0009] - ... a mechanism is provided for automatically generating a conversion 
module directly from an XML schema message definition ; [0010]; [0026] - ... a 
compilation mechanism for automatically generating the conversion module ...) 

32. As to claim 37 (Previously Presented) (incorporating the rejection in claim 1), 
Koch discloses the method wherein the payload message is transformed directly 
between the program language and the OLTP language (e.g., Fig. 1 - Legacy 
transaction framework, elements of "calling application", "Java engine", "outgoing 
message structure", "incoming message structure", and "legacy system"). 

33. As to claim 39 (Previously Presented) (incorporating the rejection in claim 15), 
Koch discloses the method wherein the payload message is transformed directly 
between the program language and the OLTP language (e.g.. Fig. 1 - Legacy 
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transaction franneworl<, elements of "calling application", "Java engine", "outgoing 
message structure", "incoming message structure", and "legacy system"). 

34. As to claim 43 (Previously Presented) (incorporating the rejection in claim 28), 
Koch discloses the method wherein the payload message is transformed directly 
between the program language and the OLTP language (e.g.. Fig. 1 - Legacy 
transaction framework, elements of "calling application", "Java engine", "outgoing 
message structure", "incoming message structure", and "legacy system"). 

35. As to claim 45 (Previously Presented) (incorporating the rejection in claim 32), 
Koch discloses the machine readable medium wherein the payload message is 
transformed directly between the program language and the OLTP language (e.g.. Fig. 

1 - Legacy transaction framework, elements of "calling application", "Java engine", 
"outgoing message structure", "incoming message structure", and "legacy system"). 

36. Claims 14, 23-27, 36, 38, 40-42 and 44 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Koch in view of Zorc and further in view of Boushy et al. (Pat. 
No. 6,003,013) (hereinafter 'Boushy') 

37. As to claim 14 (Original) (incorporating the rejection in claim 1 ), Zorc and Koch 
do not explicitly disclose the method wherein the OLTP language is a gaming system 
language. 
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However, in an analogous art of Customer Worth Differentiation By Selective 
Activation of Physical Instrumentalities Within The Casino, Bousiiy discloses the 
method wherein the OLTP language is a gaming system language (e.g.. Col. 6, Lines 
1 1-17 - in a preferred embodiment of the invention, CMS [Casino Management System] 
includes Report Program Generator (RPG)-based programs for on-line transaction 
processing (OLTP) application; these applications consolidate activity data at the casino 
property related to gaming, and process CPDB [Central Patron Data Base] to retrieve or 
store data, as necessary). 

Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of Boushy into the Zorc-Koch's 
system to further provide the method wherein the OLTP language is a gaming system 
language in Zorc-Koch system. 

The motivation is that it would further enhance the Zorc-Koch's system by taking, 
advancing and/or incorporating Boushy's system which offers significant advantages for 
differentiating customers according to their worth to the casino; customer information is 
accumulated at each affiliated casino through one or more LAN-based management 
systems, updated to a central patron database that is coupled to each casino LAN 
through a WAN, and made available to each affiliated casino property as needed as 
once suggested by Boushy (e.g.. Abstract, Lines 1-7) 

38. As to claim 23 (Original), Zorc discloses a method of processing messages 
comprising: 
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• receiving one or more extensible marl<up language (XML) documents (e.g., Fig. 
2, XML Message Definition; [0009] - ... directly from an XML schema message 
definition ): 

• compiling the XML documents into source code in an object-oriented program 
language based on stylesheet data (e.g., [0010] - ... automatically generating 
source code based on a marl<-up language message definition ...); 

• compiling the source code (e.g., [0009] - ... a mechanism is provided for 
automatically generating a conversion module directly from an XML schema 
message definition ; [0010]; [0026] - ... a compilation mechanism for 
automatically generating the conversion module ...); 

• the source code being generated automatically (e.g., [001 0] - . . . automatically 
generating source code based on a mark-up language message definition ...); 

• repeating the receiving and compiling of XML documents and the compiling of 
source code for a plurality of message types (e.g.. Fig. 3, element 314 - 
Message Definition) 

Further, Zorc discloses a method and system for automatically generating source 
code based on a mark-up language message definition (e.g.. Abstract) and conversion 
modules that convert some kind of internal representation of the data to an external 
representation (e.g., a specified communication message in XML format) and vice versa 
(e.g., [0023]-[0025]; [0098]), but does not explicitly disclose the XML documents being 
compliant with message rules associated with an online transaction processing (OLTP) 
language and the message rules defining markup tags for describing components of the 
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message; the stylesheet data representing a program template for a payload message 
in the program language; the source code enabling transformation of the message 
between the program language and the OLTP language; using the compiled source 
code to transform a message between the program language and the OLTP language; 

However, in an analogous art of Leverage Legacy Systems with a blend of XML, 
XSL, and Java, Koch discloses: 

• the XML documents being compliant with message rules associated with an 
online transaction processing (OLTP) language and the message rules defining 
markup tags for describing components of the message (e.g., P. 5, Sec. of 
"Conclusion" - XML . XSL, and Java ® work hand in hand to solve the complex 
problem of mainframe transaction access ... XML allows us to describe the 
structure of the COBOL transaction (compliant with message rules associated 
with an OLTP language), providing directions to the Java® engine on how to 
build the request or parse the response ...); 

• the stylesheet data representing a program template for a payload message in 
the program language (e.g., P. 2, Sec. of "XSL Style", 1®' Par. - ... use the XSL 
language for manipulating XML from one structure into another); 

• the source code enabling transformation of the message between the program 
language and the OLTP language; 

• using the compiled source code to transform a message between the program 
language and the OLTP language (e.g., P. 2, Sec. of "XSL Style", 2"^^ Par. - ... 
use XSL to format an incoming document structure to the name/value-pair 
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structure ... which the Java® code processes into the COBOL structure . XSL will 
also format the data returned from the legacy system ... Java code transforms it 
back into XML Sec. of "Combine XML, XSL, and Java to interface with 
mainframe systems", 2"^^ Par. - XML describes the structure of the data you are 
sending; Add XSL to complete some simple transformations; Use Java® to 
encapsulate it with a few simple classes; You will then leverage a host of legacy 
system transactions written decades ago and development becomes easier; In 
addition, the solution, you employ is realtime, which circumvents the frustrations 
and problems that arise from working with an extract file or batch interface; Fig. 1 
- Legacy transaction framework, elements of "Calling Application", "Java 
Engine", "Outgoing message structure", "Incoming message structure", and 
"Legacy System"; Sec. of "Conclusion" - XML, XSL, and Java work hand in hand 
to solve the complex problem of mainframe transaction access; Implementing 
XSL styling creates supplementary layers in the framework that allow the solution 
to configure changes from the application server or the mainframe programs 
without recompiling the Java code that performs the mapping; XML allows us to 
describe the structure of the COBOL transactions, providing directions to the 
Java® engine on how to build the request or parse the response) 
Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of Koch into the Zorc's system to 
further provide the XML documents being compliant with message rules associated with 
an online transaction processing (OLTP) language and the message rules defining 



Application/Control Number: 1 0/681 ,057 Page 33 

Art Unit: 2192 

markup tags for describing components of the message; tlie styleslieet data 
representing a program template for a payload message in the program language; the 
source code enabling transformation of the message between the program language 
and the OLTP language; using the compiled source code to transform a message 
between the program language and the OLTP language in Zorc system. 

The motivation is that it would further enhance the Zorc's system by taking, 
advancing and/or incorporating Koch's system which offers significant advantages that 
XML allows us to describe the structure of the COBOL transaction, providing directions 
to the Java® engine on how to build the request or parse the response as once 
suggested by Koch (e.g., P. 5, Sec. of "Conclusion") 

Furthermore, Zorc and Koch do not explicitly disclose the OLTP language being 
a gaming system language. 

However, in an analogous art of Customer Worth Differentiation By Selective 
Activation of Physical Instrumentalities Within The Casino, Boushy discloses the OLTP 
language being a gaming system language (e.g.. Col. 6, Lines 1 1-17 - in a preferred 
embodiment of the invention, CMS [Casino Management System] includes Report 
Program Generator (RPG)-based programs for on-line transaction processing (OLTP) 
application; these applications consolidate activity data at the casino property related to 
gaming, and process CPDB [Central Patron Data Base] to retrieve or store data, as 
necessary) 

Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of Boushy into the Zorc-Koch's 
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system to further provide the OLTP language being a gaming system language in the 
Zorc-Koch system. 

The motivation is that it would further enhance the Zorc-Koch's system by taking, 
advancing and/or incorporating Boushy's system which offers significant advantages for 
differentiating customers according to their worth to the casino; customer information is 
accumulated at each affiliated casino through one or more LAN-based management 
systems, updated to a central patron database that is coupled to each casino LAN 
through a WAN, and made available to each affiliated casino property as needed as 
once suggested by Boushy (e.g.. Abstract, Lines 1-7) 

39. As to claim 24 (Original) (incorporating the rejection in claim 23), Koch discloses 
the method further including using a stylesheet parser to compile the XML documents 
(e.g., P. 2, Sec. of "XSL Style", 2"^^ Par. - . . . use XSL to format an incoming document 
structure to the name/value-oair structure ... which the Java® code processes into the 
COBOL structure . XSL will also format the data returned from the legacy system ... 
Java code transforms it back into XML ...) 

40. As to claim 25 (Original) (incorporating the rejection in claim 23), Koch discloses 
the method further including: 

• receiving one or more name-value pairs for the message according to the 
program language (e.g., P. 5, 1^' bullet - since XSL is applied to the incoming 
document as well as the outgoing document, the Java engine, once written, is 
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insulated from changes in the incoming message structure; the entire DTD, or 
schema, of the incoming message could be changed completely; a programmer 
would only have to modify the XSL within this framework that styles the 
document into your name/value-pair format; 1®' Par. [after program listing] - 
essentially, the code matches the fields with value from the array and creates 
name/value pairs that are suitable for simplistic XML document); 
• generating a byte array according to the OLTP language; and transmitting the 
byte array to an application (e.g., 1®' Par. [after program listing] - data 
manipulation transforms the response from a byte array or similar structure into 
an XML document; essentially, the code matches the fields with value from the 
array and creates name/value pairs that are suitable for simplistic XML 
document). 



41 . As to claim 26 (Original) (incorporating the rejection in claim 23), Koch discloses 
the method further including: 

• receiving a byte array for the message according to the OLTP language (e.g., 1®' 
Par. [after program listing] - data manipulation transforms the response from a 
byte array or similar structure into an XML document; essentially, the code 
matches the fields with value from the array and creates name/value pairs that 
are suitable for simplistic XML document); 

• generating one or more name-value pairs according to the program language; 
and transmitting the name-value pairs to an application (e.g., P. 5, 1®' bullet - 
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since XSL is applied to the incoming document as well as the outgoing 
document, the Java engine, once written, is insulated from changes in the 
incoming message structure; the entire DTD, or schema, of the incoming 
message could be changed completely; a programmer would only have to modify 
the XSL within this framework that styles the document into your name/value-pair 
format; 1^' Par. [after program listing] - essentially, the code matches the fields 
with value from the array and creates name/value pairs that are suitable for 
simplistic XML document). 

42. As to claim 27 (Original) (incorporating the rejection in claim 23), Koch discloses 
the method wherein the object-oriented program language is a Java language (e.g.. 
Sec. of "Combine XML, XSL, and Java to interface with mainframe systems", 2"^^ Par. - 
XML describes the structure of the data you are sending; Add XSL to complete some 
simple transformations; Use Java® to encapsulate it with a few simple classes; You will 
then leverage a host of legacy system transactions written decades ago and 
development becomes easier; In addition, the solution, you employ is realtime, which 
circumvents the frustrations and problems that arise from working with an extract file or 
batch interface). 

43. As to claim 36 (Previously Presented) (incorporating the rejection in claim 1 ), 
Koch and Zorc do not explicitly disclose an online gaming system by an OTLP host and 
the wagering-related transactions and applications. 



Application/Control Number: 1 0/681 ,057 Page 37 

Art Unit: 2192 

However, in an analogous art of Customer Worth Differentiation By Selective 
Activation of Physical Instrumentalities Within The Casino, Boushy discloses the 
method further comprising: 

• providing an online gaming system by an OTLP host which uses the OLTP 
language, wherein the online gaming system processes wagehng-related 
transactions (e.g.. Col. 6, Lines 11-17 - in a preferred embodiment of the 
invention, CMS [Casino Management System] includes Report Program 
Generator (RPG)-based programs for on-line transaction processing (OLTP) 
application; these applications consolidate activity data at the casino property 
related to gaming, and process CPDB [Central Patron Data Base] to retrieve or 
store data, as necessary); and 

• providing an application at a consumer location which uses the program 
language, wherein the application provides access to the wagehng-related 
transactions for the consumer (e.g., Fig 28; Col. 7, Lines 16-24 - Also shown in 
Fig. 2B is an event management system (EMS) 240 on workstation 128 and a 
restaurant/retail point of sale system (POS) 244 coupled to workstation 148 and 
card reader 724; EMS 240 comprises software for handling ticketing information, 
reservations, and sales; POS 244 comprises accounting software for operating 
restaurants and retail venues within the casino property as well as software for 
transmitting charge information to other management systems); 

• wherein the payload message is part of at least one of the wagering-related 
transactions and comprises at least one of: a request to place an online wager. 
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or a response to the request to place the online wager (e.g., Col. 7 Line 64 
through Col. 8, Line 8 - in the preferred embodiment of the invention, the RPG 
applications of CMS are implemented in the AS400 environment of computer; in 
order to facilitate fast, real-time communication between CMS and CPDB, a 
messaging system Is implemented as part of interface module of computer and 
transaction management system of server; the messaging system functions as 
an application program interface (API) that allow the RPG applications of CMS to 
communicate with CPDB via transaction management system, with LAN/WAN 
interface coupling messages between the different communications protocols; 
Col. 8, Lines 9-31 - these user provided service applications implement functions 
for coupling data to and from CPDB in response to request from CMD; a utility 
associated with the messaging system reads the data dictionary and defines data 
structures In the AS400 system environment suitable for passing data between 
the RPG applications of CMS and the messaging system; a message 
building/parsing module uses data provided through the defined data structures 
to build message packets for transmitting requests to transaction management 
system, which directs the request to the appropriate service with the service 
applications provides analogous services for communications with DBMS). 
Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of Boushy into the Zorc-Koch's 
system to further provide an online gaming system by an OTLP host and the wagering- 
related transactions and applications in Zorc-Koch system. 
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The motivation is tliat it would furtlier enhance the Zorc-Koch's system by talking, 
advancing and/or incorporating Boushy's system which offers significant advantages for 
differentiating customers according to their worth to the casino; customer information is 
accumulated at each affiliated casino through one or more LAN-based management 
systems, updated to a central patron database that is coupled to each casino LAN 
through a WAN, and made available to each affiliated casino property as needed as 
once suggested by Boushy (e.g., Abstract, Lines 1-7). 

44. As to claim 38 (Previously Presented) (incorporating the rejection in claim 15), 
refer to claim 36 above accordingly. 

45. As to claim 40 (Previously Presented) (incorporating the rejection in claim 23), 
refer to claim 36 above accordingly. 

46. As to claim 41 (Previously Presented) (incorporating the rejection in claim 23), 
Koch discloses the method wherein the payload message is transformed directly 
between the program language and the OLTP language (e.g., Fig. 1 - Legacy 
transaction framework, elements of "calling application", "Java engine", "outgoing 
message structure", "incoming message structure", and "legacy system"). 

47. As to claim 42 (Previously Presented) (incorporating the rejection in claim 28), 
refer to claim 36 above accordingly. 
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48. As to claim 44 (Previously Presented) (incorporating the rejection in claim 32), 
refer to claim 36 above accordingly. 



Conclusion 

49. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Ben C. Wang whose telephone number is 571-270- 
1240. The examiner can normally be reached on Monday - Friday, 8:00 a.m. - 5:00 
p.m., EST. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Tuan Q. Dam can be reached on 571-272-3695. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

/Ben 0 Wang/ 
Examiner, Art Unit 2192 
June 19, 2008 



/Tuan Q. Dam/ 

Supervisory Patent Examiner, Art Unit 2192 



